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Net/One, the local area network produced by Ungermann-Bass, has been : 
installed and operated in the Georgia Tech Fully Distributed Processing : 
System's (FDPS) testbed. Currently Net/One interfaces with Prime 400, 
Prime 550, and PDP 11/85 computer: which are located in the computer lab 
and several different types and brands of ASCII, asynchronous terminals. 
This report includes a description of the design and operation of the 
various Net/One components, a discussion of the rationale for the selection 
of Net/One for installation in the FDPS testbed, our initial experiences 
with Net/One inoluding problems encountered and their solutions, and i 
concludes with a description of the plans for future enhancements to its 
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Chapter 1 Background 


Baekground 


The primary objective for installing a local area computer network was 
to provide a versatile research vehicle to investigate the concepts and 
utilization of local networking in a distributed processing environment. 

i This research is part of the Georgia Tech Research Program in Fully 
| , Distributed Processing Systems (FDPS) which also includes research on 


1.1 Objectives for Installing a Loos) Natwork 


distributed operating systems, distributed data bases, programming 
languages, theoretical and formal studies, security, fault tolerence, 
system utilization, physical interconnection and other topics. 

A secondary objective was to provide relief to the 'growing pains' 
| being experienced in the school's computer lab. Over a period of four 
years, the computer laboratory of the School of Information and Computer 
| Scienne had grown from a very small computing facility consisting of two 
: minicomputers and six terminals to its present size of ten minicomputers 
(some of which are quite large) ancessible by more than 60 termjvals. With 
each purchase of additional equipment, it had been necessary to provide a 
physical cable between each terminal and each computer that the terminal 
had to access. For terminals attached to multiple computers, a switch at 
the terminal selected the desired cable (and consequently the desired come 
puter). Not only did this require a large number of individual cables but 
some of the cables had to be extremely long to accomodate terminals located 
over 500 feet from the computer lab. The cost of material and labor to 
provide and install these cables began to escalate and the resulting web of 
cables led to frequent failures which would sometimes take days to isolate 
and correct. This method of connecting terminals to computers also resul- 
ted in each terminal requiring multiple, dedicated, computer I/0 porta, 
i.e. a dedicated port on each computer to which it had a cable. Since 
each terminal could be connected to only one computer at any given time and 
since many of the terminals were located in one-man offices and used 
infrequently, many of the computer ports remained idlo most of the day. 

A suitable local network promised solutions for each of these 
problems. The myriad of individual oables could be replaced by one coaxial 
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: Page 2 Baokground Chapter 1 
, cable. With the looal network, all computer ports were made available to 


ports as the number of concurrent users expected or allowed. (Typically it 
has been observed that the number of simultaneously active users on #ach 
system is approximately 40% of the number of terminals that originally had 
a wired port to that system.) Multiple interoonnecting cables, dedicated 
computer ports, and selector switches at the terminals would no longer be 
required, 


1.2 Rationale for Net/Qne Selection 
Net/One was selected as the local network research vehicle for three 
primary reasons. First, Net/One was one of the few local networks that was 
available for immediate shipment. Many of the other products considered 
were either still in the design phase or just beginning the prototype phase 
of development. Several of the local area network "products" were only 
proposals citing a "standard" mode of operation but not yet in the design 
phase. Second, Net/One provided the greatest configuration flexibility of | 
. the available products. The configuration and operation of Net/One is 
: almost completely controlled through software and can be modified on a port 
| by port basis. Third, Ungermann-Bass was interested in establishing a . 


all terminals; consequently, each computer needed to support only as many 
t 
H 


working relationship with Georgia Tech promising full product support as 
| well as technical advice for the Georgia Tech developed enhancements to 
7 their product line. 
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CHAPTER 2 
Net/One Desoriptioa 


2.1 Qrerview 


Net/One is a general purpose, local area communications network that 
supports point-to-point communications between digital devices such as com 
puter systems and terminals. Net/One consists of three logical components; 
network interface units (NIU) which serve as interfaces between user 
devices and Net/One, a Network Administrative Station (NAS) which supports 
configuration and monitoring of the network, and a Network Development 
System (NDS) which supports oustom program development an testing. A 
majority of the functions of NAS and NDS are implemented in a “special” NIU 
and a ZILOG 1/20 microcomputer with 65K bytes RAM. (Some debugging aids of 
the NDS are actually located on the regular NIUs). These compenents are ; 
connected by a standard coaxial cable supporting vaseboard transmission 
with a bandwith of 4 megabits/second. NIUs are connected to the coaxial 
cable by an active device known as the tap which is composed of drivers 
that transfer information between the cable and the NIU, 
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Figure 1. Diagram of a Net/One Local Network 


2.2 Network Interface Units (MIU) 


One NIU can support up to 16 asynchronous devices, or eight 8-bit or 4 
16-bit parallel devices that may differ in type, transmission rate, parity, 
flow control, disconnect sequence, etc. As shown in Figure 2, the najor 
components of an NIU are the transceiver interface, the network processor 
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beard and the application processor boards. They communicate via an 
8Mbyte/second internal data bus. The transceiver interface performs 
address recognition, packet transmission to and from the coaxial cable, 
packet framing and error detection. Bach processor board can support 4 
serial and either two 8-bit or one 16-bit parallel devices. A 2-80 
microcomputer, 64K bytes RAM and 4K bytes of PROM located cn each board ara 
used to provide a software interface to each device. In addition to device 
interfacing, the network processor board performs many functions for all 
NIU components such as controlling traffic inside the NIU, establishing and 
disconnecting virtual ocirouits, and building packet headers for outgoing 
packets, 
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Figure 2. Diagram of a Network Interface Unit (NIU) 


2.3 Network Adminjatrator Station (MAS) 
Network management is the responsibilty of the NAS. This includes 


configuring the network, monitoring network traffic, logging network events 
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and servicing requests from NIUs for down loading. As mentioned earlier, 
the functions of the NAS are implemented on a special NIU and a ZILNG 1/20 
microcomputer. 
' : Each device connected to an NIU board is controlled by a separate j 
process which must know that device's characteristics in order to correatly 
interface with it. Figure 3 contains an example of the sonfiguration 
parameter list that associates device characteriatics with individual NIU 
ports; included in Figure 3 are the characteristics of two devices on our 
network, an ordinary CRT and a PRIME computer port. 

When an NIU is initially powered up it automatically requests down- 
loading from the NAS. While the network is in operation, an NIU can be 
downloaded by pressing the "reset" switches located on the front panel of 
the NIU. When the NAS receives the request, it asks the ZILOG microcom 
puter to retrieve kernel code, programs and device characteristics to load 
in the NIU. 

The NAS has a few other features. The NAS consola is used as a log- 
ging device where NIU downloading actions and errors in the network are 
recorded, The Net/One systems administrator can connect to the NAS and use 
. special adminstrator commands to examine devices, create virtual cirouits 


A net eta ee 


between two remote devices, etc. 


2.4 Network Development Syates (NDS) 


‘ 
The NDS can be used by the Net/One user to write his own programs for i 
controlling the activities of the network. Development tools include those 1 
supported by the ZILOG 1/20 microcomputer system, i.e. editor, debugger, 
assembler, file utilities etc. plus a library of programs supplied by 
Ungermann--Bass to support customer programming. There is an interactive 
NIU debugger program and each NIJ has a test toggle switch that causes down 
loading with user specified test programs and data instead of the data 
normally down loaded by the NAS. In addition, each processor board 
(network and application) is furnished with a memory debugger and a special 
set of sockets for debugger PROMs. 
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Net/“ne Description 


Configuration Program 


Is this device serial async, 
serial syne or parallel 

Does it use standard or 
extended RS-232 signalling 

How many NULs after each 
linefeed 

How many NULs after each 
carriage return 

When echoing enabled, add 
linefeed after each carraige 
return 

How many stop bits 

How many data bits per character 

Odd parity, Even parity, or 
No parity 

Does this device support flow 
control 

Does it use characters or 
RS=232 line signals 

CTS:RTS or DSR:DTR 

Is this a command device 

Is it also a data device 

Command mode initiation character 

Backspace character 

Line delete character 

Completion character 

Should NIU commands be echoed 

Should NIU command responses be 
suppressed 

Does this device support lower 
case 

Disconnect sequence 

Should circuit data be echoed 
locally 

Input buffer size (2-254) 

Output buffer size (2-254) 

Input buffer flow control 
threshold 

Baud rate 

Should a circuit be initiated 
from this device at startup 


CRT 


serial async 
std 
0 


0 


Yes 


/LF/D/ 
No 


90 
60 
55 


9600 
No 


Figure 3. The Confizuration Program 
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2.5 Net/One Operation 
Net/One supports the CSMA/CD (Carrier sense multiple access/collision 


detection) access protocol. Both virtual circuits and datagrams are 

; allowed. Packets are broadcast over the coaxial cable and "picked up" by 
those NIU's to which they are addressed. Figure 4 gives the format for a 

Net/One packet, The local destination header contains the destination of 

the packet within the local network. If the packet is being sent to : 
another local network then the local destination is the "“gateway" NIU to 
that other network. The internet destination header then defines the final 

destination NIU of the packet in the other network. 
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(numbers below packet represent field length in bytes) 


Figure 4, A Net/One Packet 
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2.5.1 Device to Device Communication 


Each NIU has a network address, i.e. 27. ‘The network processor board 
is always known as the "a" board and its ports have addresses such as 27al, 
27a2 eee 27a6. Application boards are known as "b", "o® and "d" boards 

and their ports follow the same addressing scheme, i.e. 27b1, 2704, 27d6 
etc. 
A device can communicate with another device by requesting a virtual 
circuit to an address; this is done utilizing the connect command, i.e., 


connect 2762 


If the device connected to 27c2 is free (a device may participate jin only 
one virtual circuit at a time) a virtual circuit is established. any data 
transmitted by a device at one end of a virtual circuit is delivered to the 
other end in the same order as transmitted. Either device may 
disconnect/disestablish the virtual cirouit at any time. 
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All devices have a device "type" which can be either command, data or 
both command and data. Command devices can request virtual circuit connec- 
tions, data devices cannot request but may accept virtual cireult connec- 
tion requests and a command/data device may do eithe)’. 
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2.5.2 Sending and Recileving Packets 


NIUs control packet traffic in the network. When a device or com 
ponent of an NIU supplies the uata for a packet the network provessor board 
builds a packet header for that data and sends the packet to the transmit- j 
ter. The transmitter frames the packet, adds a CRC, and places it ina 
FIFO queue for transmission. When the packet arrives at the head or the 
queue, the receiver notifies the transmitter to place the packet on the 
coaxial cable at a time when it detects no other treffic on the cable, If 
the recei'= detects data on the network while the packet is being trans- 
ferred, i. sig:uls a "collision* to the transmitter. The transmitter 
; broadcasts a collision message to all other NIUs; those NIUs that were 

transmitting will attempt a retransmission after a random time delay. The 
local transmitter will also retransmit the packet after a random time 
delay. Transmitted packets ars kept in a circular queue where they can be 4 


retrieved for retransmission if necessary. ; : 

When a packet addressed to a receiver's NIU is detected on the or -x, 

it is queued in a FIFO buffer. A CRC check is made; if an invalid packet 

is found, it is removed from the queue and a message is broadcasted 
requesting retransmission of the packet. (All packets have a unique packet 
id). If the packet is valid an interrupt is generated to the processor 
board which will look at the packet header and, depending on the device to 
which the packet is addressed, will either receive the data or notify one 


Se an Ce 


of the applications boards to receive the data. 


2.6 Other Enhancements Available for Hat/One 
Up to this point we have described the local network that we have 


installed in the Information and Computer Science Lab at Georgia Tech. 
Since that installation, Ungermann-Bass has produced a 10Mbit/second local 
network (to which we could upgrade) and optional Ethernet compatible 
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software for the 10Mbit/second network. 
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Our ZILOG microcomputer system aurrently uses floppy disks. A 


Winchester disk drive is now available whioh, along with an IEEE 448 bus 
structure between the microcomputer and the special NIU, reduces the down- 
loading time of an NIU prosessor board from approximately 90 seconds to 19 4 
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CHAPTER 3 
Car Experiences With Net/0One 


3.1 Hardware Installation and Teating 
Net/One was installed in the ICS computer lab in September, 1981). The 


original configuration included 9 Network Interface Units (NIU's), 1 
Network Administration System (NDS) and 1 Network Development System. This 
equipment allowed for 108 general purpose asynchronous ports. (We do not 
use the parallel ports.) 


3.1.1 Flow Control 

Net/One supports three methods of f!ow control: using ASCII oontrol 
characters, using RS=-232 Request-To-Send and Clear-To-Send (RTS/CTS) 
control lines, or using the Data-Set-Ready and Data~Terminal~Ready 
(DSR/DTR) hardware control lines. None of these methods were completely 
suitable for our operation. Character flow control was not a viable option 
because several applications on the PRIME computer system already used all 
of the ASCII control characters; e.g. the full-screen editor. (Any of the 
standard ASCII control codes except null can be used; typically DC3 (ctri- 
S) is used to stop output and DC1 (control Q) is used to restart output.) 
The asynchronous communications hardware on the PRIME oomputers did not 
support RTS/CTS hardware lines nor did they support a DSR control line. 

A solution was eventually found involving the use of the PRIME's 
carrier detect line (normally used fo modem control) as a DSR control 
line. The Primos operating system was modified to use the carrier detect 
line as a flow control sense and the PRIME's carrier detect and DTR lines 
were wired to the networks DTR and DSR respectively. While implementing 
this solution, an error in the Primos operating system causing incorrect 
manipulation of the DTR control line was a. ‘covered and fixed.) 

We encountered yet another flow control problem caused by devices at 
one end of a virtual circuit receiving data at much slower speeds than 
being transferred by host computers at the other end. Net/One would not 
send an x-off signal to a transmitting device until the receiving buffer 
was 8 oharacters away from being full. If an x-off signal was sent to a 
PRIME computer, it was very likely that more than 86 characters would be 
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sent to the device before the PRIME would suspend transmission. As a 
result, slower devices like hardcopy terminals were losi:~ characters. 
Ungermann-Bass solved this problem for us by making the input buffer flow 
control threshold user-programmable in the next software release. This 
feature also enabled us to connect the PDP=-11/45 to Net/ONE. Our 11/45 did 
not support flow control; however by setting the transmission speed to 4800 
baud and setting the input buffer threshold to a high value we were able to 
get reliable transmission. 


3.1.2 Parity 


We were required to change our terminal parity standard from mark 
parity (always on) because the Net/One software restricted transmitted 
ASCTI data characters to have the parity bit odd, even, or always off 
(space parity). No provision was made to use mark psrity or to simply 
ignore the parity bit on input, Since some of the terminals we were 
currently using could not generate either even or space parity, odd parity 
was chosen as the standard for our terminals. (Since computer ports were 
data devices, we kept them configured for mark parity. If Net/One 
enoounters a parity bit set to an unexpected value, it simply "ignores" the 
byte (i.e. Net/One passea it through to the device at the other end of the 
circuit without examining the contents for a recognizable command. ) 


3.1.3 Coaxial Cable Connections and Terminators 
After solving flow control and parity problems the network was still 


unstable. It took us a while to discover that the cause was a faulty 
terminator that was reflecting signals back into the coaxial cable. We 
also discovered that connecting the pieces of the coaxial cable is not easy 
or foolproof. If one connection anywhere along the coaxial cable is 
faulty, the entire local network becomes unstable. Best results were 
obtained when we connscted the cable in a straight line (i.e. no "T*® oon- 


nections). 
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3.2 Software installation and testing 


3.2.1 Release 1.2 
The original Net/One software, release 1.2, provided the following 


; 
j 
i 
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commands to Net/One users: 


Command Exolanation : 
connect device <address> virtual cirouit request : 
<LFOD virtual ciroyit disconnect | 
list disconnect list disconnect command 
list address list my network address 


Figure 5. Some Net,/One User Commands 


Commands could be abbreviated to the first letter of each word, i.e. "c d 

27a3" for "connect device 27a3*. 
There were a few shortcomings in release 1.2. Users had to know all 

of the specific network addresses assigned to e computer system that they 

wanted to access. Network address assignment was governed more by physical 

proximity of the NIU which did not necessarily follow a logical order. If 

for some reason, a computer port address had to be moved, all users needed 


to be notified of the change. If the first connect was unsuccessful 
because the port at the specified address was already participating in 
another virtual circuit, the user was required to repeat the connect 
sequence for other addresses until a free port was found. 

Other problems resulted from Net/One's non-transparent transmission of 
some characters. Specifically, some of the ASCII control characters were 
incorrectly interpreted and/or were not passed through the virtual cirouit. 
This problem was first observed with programs that controlled the cursor 
positioning on some brands of CRT terminals. It was later discovered that 
the break key, used by the Prime computers as a software interrupt signal, 
was transmitted through the virtual circuit as an ASCII NULL which the 


ae inne 


PRIME computer ignored. 


302.2 Release 2-1 


In March, 1981, release 2.1 arrived. There were a few new features 
acd several improvements over the original software release. The most wel- 
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come of the new features was the global network name server, This feature 
allowed a local network user to request a virtual cirsuit oy specifying a 
symbolic name. The nane serve: then broadcasted the request to all network 
ports. Any of the network ports that had been configured to respond to 
that name and that were not currently part or a virtual oirouit would ack- 
nowledge the request, When the circuit was established, the user received 
confirmation showing the physical network address that accepted the conneo- 
tion request. If all network ports oo.Sigured with that symbolic name were 
currently tied up in another virtual oirocuit, the user received the message 
"All ports are busy'. If no network porta were configured with that name 
or if none of the configured ports were operational, the user received the 


a a ia lo 


message 'No resource answers by that name‘, 

Other major enhancements were made to the configuration program. The 
program was much easier to use and added such features as extended RS-232 
line signals for serial and parallel ports and user programmable input 


buffer flow control thresholds. 


3-3 IncHouse Modifications to Met/One Software 
With a small modification to the PRIMOS operating system and ccorrec- : 


tions to the Net/One software from Ungermann-Bass, we implemented a method 
of forcing a virtual cirouit disconnection when a Prime computer user iog- 
ged off. The local network made logging on and off a two atep process: 
requesting/disconnecting a virtual cirouit and logging-on/logging-off a 
computer system. Many users were logging off but not disconneoting the 
virtual circuit thus not freeing that computer port for another user. This 
modification oaused automatic virtual circuit disconnection when the user 
logged off. In order to implement this facility, it wes necessary to 
reconfigure all our network computer ports and computers to use odd parity. 
(Since we wanted Net/One to recognize the disconnect sequence issued by the 
computer, each character of the disconnect sequence had to have the parity 
bit set to something that Net/One understood.) 

Another correction to the Net/One software removed the sensitivity to 
This correction ailowed the use of cursor--positioning 
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ASCII control codes. 
programs with no restrictions. 
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3.4% Current nerformance 
Curre cly, we have 10 NIUs with 128 available ports of which only 11 


are not yet connected to any device. 44 computer ports provide access to 
five PRIME computers running Primos and a PDP 11/45 computer running Unix 
version 7. Most devices run at 9600 baud. 

We have not as yet made any in-depth performance analyses of Net/One. 
However, we have brad Net/One for almost a year and once /nstalled we nevor 
witnessed any component failures nor were we ever required to bring the 
network dewn because of hardware or software probleas (and we purchase. one 
of the first Net/One networks manufactured). Our computer systems perform ; 
charaater echoing for all terminals, and oven with heavy terminal aotivity 
we have never noticed any delays induced by Net/One. Finally, both our 
novice and very experienced users have found that Net/One is easy to use. 
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3-5 Unaclyed Problems 

There remain a few problems with Net/One that both Georgia Tech and 
Ungermann-Bass are attempting to solve. Some of these problems are addres- 
sed in Revision 3.0, soon to arrive. Net/One sti.l transmits break charaoc- 
ters as ASCII NULLS. Users cannot send one character that metohes tae : 
first character of the disconnect sequence because that character is not 
transmit. .d util another character not in the disconnect sequence is 
tyred. Also, the Local network remains sensitive to the ASCII parity bit. 

Occasionally, a virtual circuit is broken by the network. This leaves 
(he computer user logged in to the computer. Sino the cirouit to that 
; conputer no longer exists, any other terminal user may connec’ to that com 
futer port. and find himseif in the middle of the terminal seasion of the 
i user whose circuit was oroken. (We have just recently received a patch for 
Revision 2.1 software that appears to take care of this problem). Also, 
2ccasionally, a aumber of Net/One ports becomes unavailable to the rest of 
the local network for no reason. Typically, this problem occurs with 
groups of 4 network ports up to and including un entire NIU (16 ports). in 
order to make these ports usable again, it is necessary to reload the NIU. 

Reloading an NIU is very easy. It requires pressing reset switches on 
the front panel of the NIU and then waiting approximately 90 seconds per 
board. However, there is no provision for reloading only one board. If we 
Need to reconfigure a port or if a board hangs, we must ask all users cot 
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| nected to other ports on the NIU to log ff vatil the NIU is reloaded. i 
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CHAPTER & 
Putu..e Plans for Net/One 


4.1 Seourity 
Working closely with Ungeruann-Bass, we plan to deve':' 1 seourity 


system within the local network. Firat, we expeot to implement a pasaword 
seourity system requiring a pasaword to be supplied and checked before a 
new virtual circuit can be established. This will bt used to control 
access to those systems that require additional seourity such as those used 
for research, Our general access computers will not require a password for 
connection. 

We also plan to implement an access list seourity system within the 
local network. The access list seourity will allow connections to specific 
computers from a list of terminal locations. This will serve to further 
deter non-authorized usage of sensitive resources. 

Related to the security system will be the implementation of a one- 
step login process. This would involve a command such as 


,ogin <username> <project> 


that would cause the local aetwork to create a virtual cirouit to the com 
puter system associated with the usernmme and pruject information and then 
execute a surrogate login for the user. The next thing that the user would 


see is the password prompt. 


B.2 X25 
We propose to use a portion of the X.25 interface batween the host and 


the NIU to act as an X.25 DCé to support multiple virtual cirouits on one 
physical connection. Also, an implementation of the X.25 DTE protocol in 
an NIU is desired to allow direct connection between Net/One and an X.25 


Public Packet Switched Network, e.g. Telenet. 
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4.3 Parformance Studies 


We plan to carry out some performance studies on the local network. 
Partioularly, we would like to find out how much traffic it takes to induce 


a noticable degredation of Net/One performance. 


See OED OE 


4.§ Additional Service 


We are planning to expand the ourrent local network hardware to sup- 


port more terminal users and computer systens. Figure 6 contains the 


diagram of our future local network. The first step of the expansion has 
been to order 20 additional Net/One ports raising our ourrent network port 


(When fully expanded, the Net/One local network can support 
We will 


count to 144, 
255 NIU's for a total of 4080 general purpose asynchronous ports). 
eventually support the following computers: 

(1] IBM Seriec/1 running under the EDX operating system. 
have three of these machines in our computer lab used for both academic and 


Te SR 
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We ourrently 


research purposes. 
[2] HP 1000 F series under the RTE IV B operating system, This system 


é : will be used as a graphics support processor driving several Hewlet Packard 
, graphics dev'ces including a plotter and color graphics terminals. This | 

system supports mainly an academic user community. 
(3] VAX 11/780 running under the VAX Unix version 7 operating system. 
This system will also be used to link Georgia Tech to CSNEL, the national 


computer science network. 
rs [4] CDC Cyber 74% running under the NOS version 1.4 operating system. 


This computer along with a CDC 6400 supplies the Georgia Tech campus with 


general computing resources. 
[5] Several single user microcomputer workstations capable of stand~ 


alone network operation. 
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Figure 6. Our Future Local Computer Network 
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